Subject: Spec Fixes

From: "Jack Sanders" <[email-masked]>
Date: Mon, 11 Apr 94 12:01:45 EDT

The following corrections are proposed to the CPI-C Spec.  Please send
any comments or questions to me at [email-masked].  Otherwise
the corrections will added to the Spec as described.  Thanks to those who
have contributed these corrections.

Some changes (specifically 1, 3, 4, 5, 6, 7, and 9) have already been
applied to the CPI-C Spec review copy now on the document library.

Regards,
Jack
----------------------------------------------------------------------
Change 1 - Format of AE_Qualifier

Rationale:  The format of AE_Qualifier should specify that it is either
CM_DN or CM_INT (and not CM_OID).  This is compatible with ISO 8650.

Fix:  Make appropriate changes to the Set_AE_Qualifier and
Extract_AE_Qualifier calls and to the pseudonym files.

-----------------------------------------------------------------------
Change 2 - Add Extract_Transaction_Control call to the state tables.

Rationale:  obvious

Fix:  Add the missing call to both the half-duplex and full-duplex state
tables.

-----------------------------------------------------------------------
Change 3 - TP_READY indication mapping

Rationale: After a Prepare call, a program is informed of the partner
program's preparation of resources for commit by a status_received value
of CM_PREPARE_OK.  The TP-READY request carries the information to the
local system.

Fix:  In sections D.2.3 Mapping OSI TP Services to CPI-C for Half-Duplex
Conversations and D.3.1 Mapping OSI TP Services to CPI-C for Full-Duplex
Conversations, replace

   TP_READY indication       (Handled by a resource recovery component.)

with

   TP_READY indication        completes an outstanding
      (no parameters)            CM_RCV - Receive
                              and maps to
                                 status_received = CM_PREPARE_OK.

-----------------------------------------------------------------------
Change 4 - Prepare_Data_Permitted for FDX conversations

Rationale:  The description of the prepare_data_permitted characteristic
is inaccurate for full-duplex conversations.  In particular, OSI TP does
not make use of the characteristic for full-duplex conversations, and the
subordinate is always permitted to send data after the superior issues a
Prepare.  For LU 6.2, data is not permitted after Prepare.

Fix 1:  Split Table 9, Possible Take-Commit Notifications, into two
tables, one each for half-duplex and full-duplex conversations.  Clarify
that for a FDX conversation using an OSI TP CRM, a Prepare call by the
superior results in a take-commit notification ending in _DATA_OK, and
the subordinate is able to send data after receipt.  For a FDX
conversation using an LU 6.2 CRM, the take-commit notification does not
end in _DATA_OK, and the program is not able to send data after receipt.

Fix 2:  Make analogous modifications to the description of the
status_received variable in the Receive call.

Fix 3:  Add to the Set_Prepare_Data_Permitted call description that the
prepare_data_permitted characteristic applies only to half-duplex
conversations.

-----------------------------------------------------------------------
Change 5 - Set_Initialization_Data FDX state table correction

Rationale:  Set_Initialization_Data can be issued only in Initialize or
Send-Receive states on a full-duplex conversation.

Fix:  Correct the full-duplex state table for the Set_Initialization_Data
call.

-----------------------------------------------------------------------
Change 6 - OSI TP mapping table for Confirm call

Rationale:  Confirm cannot be issued in Receive state and cannot be the
first activity on a half-duplex conversation after Accept.

Fix:  Delete, in the OSI TP mapping table for half-duplex conversations,
the first If statement for the Confirm call, having to do with the first
activity after Accept.

-----------------------------------------------------------------------
Change 7 - OSI TP mapping for Prepare_To_Receive (sync_level), and
for Confirm and Flush in Defer-Receive state.

Rationale:  For a half-duplex conversation with sync_level set to
CM_SYNC_POINT or CM_SYNC_POINT_NO_CONFIRM, the conversation goes to
Defer-Receive state when Prepare_To_Receive (sync_level) is issued.  The
Prepare_To_Receive maps to an OSI TP service request that depends on the
next operation on the conversation.  Specifically, after
Prepare_To_Receive (sync_level), a Flush call maps to a TP-GRANT-CONTROL
request; a CONFIRM call maps to a TP-HANDSHAKE-AND-GRANT-CONTROL request;
a commit or Prepare call maps to a TP-DEFERRED-GRANT-CONTROL request
followed by a TP-COMMIT or TP-PREPARE request.

Fix:  Add to the mapping tables for half-duplex conversations for the
Flush and Confirm calls to indicate this mapping, and indicate for
Prepare_to_Receive (sync_level) how the mapping depends on the following
operation.

-----------------------------------------------------------------------
Change 8 - Clarify the relationship between TX Transaction_Control
and the transaction_control conversation characteristic.

Rationale:  The relationship between the TX Transaction_Control and the
CPI-C transaction_control characteristic needs clarification.
Specifically, a program can not allocate a protected conversation with
transaction_control set to CM_CHAINED_TRANSACTIONS unless the
conversation's context is in transaction.  And when a
program using TX Transaction_Control set to TX_UNCHAINED issues a commit
call on conversation with the transaction_control characteristic
set to CM_CHAINED_TRANSACTIONS, the system deallocates the conversation
after the commit processing completes.

Fix 1:  Modify the description in Section 2.14.5, Chained and Unchained
Transactions, to read:

2.14.5 Chained and Unchained Transactions

When a program is using the X/Open TX resource recovery interface, it may
choose when the next transaction is started after the current transaction
ends.  Specifically, if the TX Transaction_Control variable is set to:

 - TX_CHAINED, a commit call ends the current transaction and
   immediately begins the next transaction and establishes a new sync
   point.
 - TX_UNCHAINED, a commit call ends the current transaction but does not
   begin the next transaction.  The program that issued the commit call
   to end the current transaction must issue the tx_begin call to the
   X/Open TX interface to start the next transaction and to establish a
   new sync point.

For a conversation using an OSI TP CRM, the program that initializes a
conversation may use the Set_Transaction_Control call to specify whether
it wants to use chained or unchained transactions for the conversation.
The remote program may determine whether chained or unchained
transactions are being used for the conversation by issuing the
Extract_Transaction_Control call.  A conversation using an LU 6.2 CRM
must use chained transactions.

For a conversation using chained transactions, if a commit call ends the
current transaction and immediately begins the next transaction, the
conversation is automatically included in that next transaction and is
always a protected conversation.  If the commit call does not immediately
start the next transaction, the conversation is deallocated by the
system, and the program is notified of the deallocation by a
CM_RESOURCE_FAILURE_RETRY return code.

For a conversation using unchained transactions, when a commit call ends
the current transaction, the conversation is not automatically included
in the next transaction.  Until the next transaction is started and the
conversation is included in that transaction, the conversation is not a
protected conversation, and any commit or backout processing does not
apply to that conversation.  After the next transaction is started, the
conversation is included in that transaction, and becomes a protected
conversation again, when the program requests that the partner program
join the transaction.

The TX Transaction_Control variable and the CPI Communications
transaction_control conversation characteristic are independent.
There are four possible combinations:

          - TX_CHAINED    and  CM_CHAINED_TRANSACTIONS
          - TX_CHAINED    and  CM_UNCHAINED_TRANSACTIONS
          - TX_UNCHAINED  and  CM_CHAINED_TRANSACTIONS
          - TX_UNCHAINED  and  CM_UNCHAINED_TRANSACTIONS

Fix 2:  Add the following condition code under the
CM_PROGRAM_STATE_CHECK return code for the Allocate call:
  - sync_level is set to CM_SYNC_POINT or CM_SYNC_POINT_NO-CONFIRM,
    transaction_control is set to CM_CHAINED_TRANSACTIONS, and the
    conversation's context is not in transaction.
-----------------------------------------------------------------------
Change 9 - Prepare issued in transaction only

Rationale:  A program can not issue a Prepare call on a conversation
unless the converation's context is in transaction.

Fix:  Add the following condition under the CM_PROGRAM_STATE_CHECK return
code for the Prepare call:
  - The conversation's context is not in transaction.  The program must
    issue a tx_begin call to the TX interface to start a transaction.
------------------------------------------------